Internet Tools (InfoMagic)/Internet Tools.iso/dos_win/winsock/maillist/94-05.Z/94-05/[e-mail]_Wed May 11 00:49:04 1994.msg

Internet Message Format | 1994-05-31 | 7KB

Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA02802; Thu, 12 May 1994 09:15:08 -0400
Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
          id AA34167; Thu, 12 May 1994 08:50:22 -0400
Received: from GATEWAY by bigblue with netnews
    for [e-mail] ([e-mail])
To: [e-mail]
Date: Wed, 11 May 1994 00:49:04 GMT
From: [e-mail] (Paul Brooks)
Message-Id: <[e-mail]>
Organization: TurboSoft Pty Ltd, Sydney, Australia
Sender: ses
References: <2qmtc5$[e-mail]>
Subject: Re: How is it meant to be implemented?

In article <2qmtc5$[e-mail]> [e-mail] (J. S. B'ach) writes:
|What is the intended implementation for the cancel blocking/async call
|parts of the winsock API?  Or how did anyone out there actually
|implement it?

All Winsock vendors have/should have implemented it - its not that hard
a concept, really.

Windows is sort-of multi-tasking. While one program is doing something,
another can do something that interrupts it. In the case of
a blocking sockets call, for example 'recv()' on a socket with no data,
the WINSOCK.DLL (or some underlying layer) will be sitting in a loop
running something like:

    while (!Cancelled)
    {    if (Data_has_Arrived)
        {    Copy_to_user_buffer();
            return;
        }
        Yield_to_windows();
    }
    return (WSAINTR);

where Yield_to_windows() is similar to the sample default blocking hook
in the Winsock manual - i.e., it calls Peek_Message() or similar,
that returns control to Windows, allowing other apps to run.
    While Windows has control, the message loop within the application
that is waiting for the data may be activated, and the user may have
pressed a "Cancel" button, in which case the application will call
WSACancelBlockingCall(), which will set the "Cancelled" variable
associated with the socket.
    When Windows has finished there and returns control to the
DLL, it will find the "Cancelled" variable has been set, and return
back to the app. that called it.

WSACancelAsyncCall() works similarly. A previous Async. call that
has not yetr returned will have some sort of data structure allocted within,
so the DLL can associate the reply with the correct app. and post
the required message. Calling WSACancelAsyncCall() tells the DLL to clean
up the data structure, as the answer is not needed. When/if the answer does
come back, it will be ignored.

Hope this helps.

--
Paul Brooks              |[e-mail]       |Emerging Standard:
TurboSoft Pty Ltd        |[e-mail]|  one that has not yet
579 Harris St., Ultimo   |                         |  been superseded.
Sydney Australia 2007    |ph: [phone]       |
From [e-mail] Thu May 12 05:27:46 1994
Received: from ftp.com (wd40.ftp.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA05149; Thu, 12 May 1994 09:25:14 -0400
Received: from ftp.com by ftp.com  ; Thu, 12 May 1994 09:25:07 -0400
Received: from mailserv-B.ftp.com by ftp.com  ; Thu, 12 May 1994 09:25:07 -0400
Received: from backman.minimillian by mailserv-B.ftp.com (5.0/SMI-SVR4)
    id AA21681; Thu, 12 May 94 09:27:46 EDT
Date: Thu, 12 May 94 09:27:46 EDT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: *** WinSock 2 Interop Meeting Agenda ***
From: [e-mail]  (Larry Backman)
Cc: Multiple recipients of list <[e-mail]>
Sender: [e-mail]
Repository: mailserv-B.ftp.com, [message accepted at Thu May 12 09:27:39 1994]
Originating-Client: minimillian
Content-Length: 3677


 >> From [e-mail]  Thu May 12 07:32:31 1994
 >> Received: from ftp.com by mailserv-B.ftp.com (5.0/SMI-SVR4)
 >>         id AA20304; Thu, 12 May 94 07:32:31 EDT
 >> Errors-To: [e-mail]
 >> Received: by ftp.com  ; Thu, 12 May 1994 07:29:51 -0400
 >> Received: by ftp.com  ; Thu, 12 May 1994 07:29:51 -0400
 >> Received: from ftp.com by ftp.com  ; Thu, 12 May 1994 07:29:44 -0400
 >> Received: from calypso-2.oit.unc.edu by ftp.com  ; Thu, 12 May 1994 07:29:44 -0400
 >> Received: from  (localhost.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
 >>           id AA29365; Fri, 29 Apr 1994 20:18:28 -0400
 >> Date: Fri, 29 Apr 1994 20:18:28 -0400
 >> Errors-To: [e-mail]
 >> Reply-To: [e-mail]
 >> Originator: [e-mail]
 >> Sender: [e-mail]
 >> Precedence: bulk
 >> From: Martin Hall <[e-mail]>
 >> To: Multiple recipients of list <[e-mail]>
 >> Subject: *** WinSock 2 Interop Meeting Agenda ***
 >> X-Listprocessor-Version: 6.0a -- ListProcessor by Anastasios Kotsikonas
 >> content-length: 1997
 >>
 >> Firstly let me apologize for the lateness of organizational
 >> details for the Interop meeting. We were failed by the list
 >> at the end of the day which stopped any email finding its
 >> way to WinSock folks. There will therefore be people who'd
 >> like to be at Interop but can't be because of how late
 >> they learnt about the event. Fear not. We will publish a
 >> revised framework & requirements document after that event
 >> which we will give folks a chance to comment on before we all
 >> start executing on it.
 >>


 Martin:

 As one of the original people involved in Winsock and one of the
 people who have put an awful lot of effort into making Winsock
 the success that it, is I am dismayed by the continual inability
 of the Winsock coordinaters to communicate in a clear and consistent
 fashion what is and isn't going on with respect to ongoing Winsock
 work.

 I'm distressed at the attitude that sending out a message on 4/29
 (which arrived 5/12) for a meeting on 5/3 is considered acceptable.
 This is not the first nor the second nor the third time this
 has happened.  Nor do I find it acceptable to blame the list processor
 for the failure to communicate.  Those of us with budgets do not
 appreciate the $1,000 3 day in advance airfare prices we have continually
 been exposed to for each and every Winsock meetings.  Those of us with
 product schedules to meet do not appreciate having to pick key developers
 up on 3 days notice and send them somewhere for yet another inconclusive
 Winsock meeting.

 At the same time; those of us in the protocol stack business realize the
 importance of Winsock and the importance of making Winsock II improve
 on the deficiencies of Winsock I.  As a result; each time the Winsock
 piper calls; off goes a developer to the latest Winsock ball.  While this
 is good for Winsock it is not good for the manager who has to perpetually
 justify internally why a key developer is going off at a moments notice
 to yet another Winsock meeting.

 It is clear to me that if Winsock II is to succeed much more consistent
 and constant communications from the Winsock coordinators to the masses
 must occur.  Likewise; from a business management perspective; if the
 Winsock coordinators want participation from others than the
 "gang of 4" and true multi-vendor cooperation and interoperability
 a lot more effort needs to go into leveling the playing field such that
 other vendors can both participate and be heard on an equal basis.

 Larry Backman
 Director of Engineering
 FTP Software